The subject matter discussed in this section should not be assumed to be prior art merely as a result of its mention in this section. Similarly, a problem mentioned in this section or associated with the subject matter provided as background should not be assumed to have been previously recognized in the prior art. The subject matter in this section merely represents different approaches, which in and of themselves can also correspond to implementations of the claimed technology.
The technology disclosed relates to non-intrusively enforcing security during federated single sign-on (SSO) authentication without modifying a trust relationship between a service provider (SP) and an identity provider (IDP). In particular, it relates to configuring the IDP to use a proxy-URL for forwarding an assertion generated when a user logs into the SP, in place of an assertion consumer service (ACS)-URL of the SP. It also relates to configuring an assertion proxy, at the proxy-URL, to use the SP's ACS-URL for forwarding the assertion to the SP. It further relates to inserting the assertion proxy in between the user's client and an ACS of the SP by forwarding the assertion to the SP's ACS-URL to establish a federated SSO authenticated session through the inserted assertion proxy.
The explosive growth of cloud applications and, in particular, Software-as-a-Service (SaaS) applications has changed the way organizations do business. Lower maintenance costs, increased uptime, faster feature rollout, and the reduced need for on-site hardware are just some of the reasons why cloud-based SaaS solutions are making deep and fast inroads to tasks that were formerly dominated solely by in-house IT staff.
However, user identity management (UIM) on SaaS applications is difficult, time consuming, and expensive. To address the challenges and cost of UIM, many enterprises that subscribe to SaaS applications are turning to Identity-as-a-Service (IDaaS) solutions to easily create and manage user identities across their entire portfolio of SaaS application subscriptions, which usually span multiple platforms and can change often.
IDaaS solutions give users federated Single Sign-on (SSO) capability or federated identity across all of an organization's SaaS application subscriptions. SSO allows users of an organization to authenticate at a single location, with a single account, and access a broad range of SaaS applications. With SSO, a user does not need to be signed on several times to call various applications, and can reuse the authenticated status of a previous application in the same session. The benefit of using SSO is that it reduces human error and saves time spent in authenticating with different SaaS applications for the same identity. Numerous mechanisms implement SSO between an IDaaS provider and a plurality of SaaS applications. For example, SSO is facilitated by Security Assertion Markup Language (SAML). SAML is an extensible markup language (XML)-based open standard data format for communicating security information (authentication and authorization data) between an entity that provides user identities, i.e. an identity provider (e.g., IDaaS), and an entity that provides the service that the user needs to log in to, i.e. a service provider (e.g., SaaS application). Other examples of SSO implementation mechanisms include WS-Federation, OAuth, OpenID, LDAP, Kerberos, SecureID, Shibboleth System, eXtensible Access Control Markup Language (XACML), and Service Provisioning Markup Language (SPML).
Besides SSO, organizations have a requirement for monitoring, moderating, and curtailing access to the subscribed SaaS applications by way of a so-called cloud access security broker (CASB). However, most organizations cannot effectively use both an IDaaS solution to implement SSO, which requires establishment of a trust relationship between the IDaaS provider and the SaaS applications through direct communication, and a CASB server, which modifies the trust relationship by interrupting the direct communication required for SSO.
As SaaS adoption by the enterprise continues to grow, so does the need to monitor, moderate, and manage access to the SaaS applications. The limited capabilities of existing CASB servers would require the setup of an improved CASB server that enforces cloud security in a non-intrusive manner without modifying the trust relationship between an organization's IDaaS subscription and its SaaS application subscriptions.
Therefore, an opportunity arises for the development of an enhanced CASB to overcome the above mentioned limitations of existing CASBs.